[core] Make hook.metadata a lazy Promise getter - #3988

• abortAlreadyAbortedWorkflow: pre-aborted signal seen by step (fastify)
• abortExternalSignalWorkflow: signal passed as workflow input (sveltekit)
• abortFetchUncaughtWorkflow: uncaught fetch AbortError is FatalError, no retries (fastify)
• abortHookOrderingWorkflow [hook-first-hook-first]: hook.then → addEventListener → resumeHook → abort() (fastify)
• abortHookOrderingWorkflow [listener-first-abort-first]: addEventListener → hook.then → abort() → resumeHook (nest)
• abortReasonTypesWorkflow: various abort reason types propagate correctly (vite)
• abortViaHookWorkflow: external hook triggers abort on in-flight step (nest)
• Calculator.calculate - static workflow method using static step methods from another class (hono)
• cancelRun via CLI - cancelling a running workflow (express)
• cancelRun via CLI - cancelling a running workflow (nextjs-turbopack)
• concurrent hook token conflict - two workflows cannot use the same hook token simultaneously (astro)
• concurrent hook token conflict - two workflows cannot use the same hook token simultaneously (fastify)
• cross-file imports preserve message and stack trace (tanstack-start)
• cross-file step error preserves message and function names in stack (astro)
• crossContextSerdeWorkflow - classes defined in step code are deserializable in workflow context (nuxt)
• customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE (example)
• customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE (sveltekit)
• customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE (tanstack-start)
• distributedAbortController - manual abort triggers signal (hono)
• distributedAbortController - reconnect to existing controller (sveltekit)
• FatalError fails immediately without retries (example)
• getterStepWorkflow - getter functions with "use step" directive (nuxt)
• hookAdoptOwnerResultWorkflow - duplicate adopts the owner result via conflict.returnValue (python)
• hookCleanupTestWorkflow - hook token reuse after workflow completion (hono)
• hookCleanupTestWorkflow - hook token reuse after workflow completion (nextjs-webpack)
• hookCleanupTestWorkflow - hook token reuse after workflow completion (sveltekit)
• hookDisposeTestWorkflow - hook token reuse after explicit disposal while workflow still running (fastify)
• hookGetConflictThenStepParallelWorkflow - hook.getConflict() continuation step runs alongside other steps (python)
• hookGetConflictWorkflow - hook.getConflict() resolves with the conflicting run when token is already registered (nextjs-webpack)
• hookSignalOwnerWorkflow - duplicate forwards its payload to the owner via resumeHook (nitro)
• hookSupersedeOwnerWorkflow - duplicate cancels the owner and claims the released token (nuxt)
• hookTokenReuseLoopWorkflow - same run recreates a hook with the same token after dispose() (hono)
• hookTokenReuseLoopWorkflow - same run recreates a hook with the same token after dispose() (vite)
• hookWithSleepWorkflow - hook payloads delivered correctly with concurrent sleep (nextjs-webpack)
• hookWorkflow is not resumable via public webhook endpoint (example)
• hookWorkflow is not resumable via public webhook endpoint (nextjs-webpack)
• hookWorkflow is not resumable via public webhook endpoint (python)
• mixed provider and function tools (nextjs-webpack)
• nested function calls preserve message and stack trace (vite)
• no startIndex (reads all chunks) (express)
• promiseRaceWorkflow (python)
• resume-or-start route pattern - resumeHook retried after start() reaches the new run (nextjs-webpack)
• retainedInterleavingWorkflow (astro)
• retainedInterleavingWorkflow (nest)
• RetryableError respects custom retryAfter delay (nuxt)
• runClassSerializationWorkflow - Run instances serialize across workflow/step boundaries (express)
• sleepWithSequentialStepsWorkflow - sequential steps work with concurrent sleep (control) (example)
• sleepWithSequentialStepsWorkflow - sequential steps work with concurrent sleep (control) (fastify)
• step throw of a non-Error value preserves it as cause on the wrapping FatalError (nuxt)
• stepFunctionPassingWorkflow - step function references can be passed as arguments (without closure vars) (tanstack-start)
• stepWinsRaceWorkflow (hono)
• stepWinsRaceWorkflow (nextjs-webpack)
• thisSerializationWorkflow - step function invoked with .call() and .apply() (example)

✅ ▲ Vercel Production

✅ 💻 Local Development

✅ 📦 Local Production

✅ 🐘 Local Postgres

✅ 🪟 Windows

✅ 🌐 Cross-language Conformance

❌ vercel-http-transport

✅ vercel-multi-region

✅ vercel-ws-transport

1020 steps (inline)

Cumulative STSO time: main 133880ms → this run 140316ms (Δ +6436ms, +5%)

 50-100 ms  ┃                         main   2  this   0    -2
100-150 ms  ██████████████████████┃█  main 884  this 849   -35
150-200 ms  ███┃                      main 118  this 154   +36
200-250 ms  ┃                         main  11  this   5    -6
250-300 ms  ┃                         main   3  this  10    +7
350-400 ms  ┃                         main   1  this   1    +0

variant  RTT 1ms→5s+             avg         p50           p90           p99     n
control  ······▂█▄▁▁▁·  385.7 (+98%)  149 (-16%)  1330 (+290%)  3137 (+386%)  3000
sweep    ······▂█▃▁···  163.3 (-34%)  141 (-31%)    358 (-32%)    700 (-29%)  3000
gw 1x    ·····▁▃█▂▁···  137.9 (-24%)  118 (-18%)    254 (-43%)    440 (-41%)  5295
eve 1x   ·····▁▆█▁··▁·  192.4 (-31%)  107 (-25%)    185 (-71%)   4487 (+10%)  5186
eve 2x   ·····▁▃█▃▁···  158.9 (-40%)  137 (-41%)    305 (-48%)    496 (-40%)  7779

RTT over stream progress (avg per tenth of stream, bars scaled min→max):

control  █▇▅▇█▆▄▃▂▁  235–491ms
sweep    ▅▅█▇▄▁▂▂▂▁  136–208ms
gw 1x    ▅▃▃▁▂▂▂█▂▄  119–179ms
eve 1x   ▁▁▁▁▁▁▁▁▁█  98–889ms
eve 2x   ▁▁▂▁▁▂▃█▄▂  125–279ms

RTT by chunk size (avg per log size bin, ~160B → ~12KB serialized, bars scaled min→max):

sweep  ▆█▆▁▃▂▅  162–165ms

Delivery jitter over stream progress (avg positive CDV per tenth of stream, bars scaled min→max):

control  ▃▂▁█▃▃▂▃▃▁  32–91ms
sweep    ▃█▇▇▄▆▁▄▄▂  43–70ms
gw 1x    ▅▆▄▁▄▅▆█▃▅  31–51ms
eve 1x   ▂▂▂▁▂▂▂▁▂█  19–58ms
eve 2x   ▃▇▂▁▄▃█▆▅▆  21–27ms

01f8f8d

Wed, 09 Sep 2026 17:41:20 GMT · run logs

vercel / nextjs-turbopack

Streams

b89b982

Fri, 04 Sep 2026 21:25:30 GMT · run logs

vercel / nextjs-turbopack

Streams

_{Streams: first-chunk RTT (the stream-open path, before any buffering/backpressure), CRTT percentiles, and worst delivery stall (CDV max). Cells are medians across iterations; per-run values in the artifacts. No 🔴/🟢 marks until targets attach.}

_{The collapsed STSO distribution section above buckets every step gap, split inline (same warm process — pure framework overhead) vs queue-hop (fresh process — dispatch, reinit, replay). █ = main, ┃ = this run, ░ = fill.}

_{The collapsed CRTT drill-down: per-variant RTT histograms (fixed log bins, · = empty) and mean RTT/positive-CDV profile lines over stream progress and chunk size. Histograms, avgs, and profiles merge exactly across runs; p50–p99 are percentile-of-percentiles. Per-index rows live in the artifacts.}

_{Best/P75/P90/P99 deltas compare against the most recent benchmark run on main at the time of this run. 🔻 flags a delta worse than +15%, 💚 one better than −15%.}

_{Metrics — TTFS: time to first step body (in-deployment start() → first step body) · Fan-out TTFS: fan-out time to first step (in-deployment start() → first of the parallel step bodies to complete) · Fan-out TTLS: fan-out time to last step (in-deployment start() → last of the parallel step bodies to complete, i.e. when the Promise.all resolves) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · CRTT: chunk round-trip time (per-chunk write → read latency, one clock domain: deployment → stream backend → same deployment) · CDV: chunk delay variation / delivery jitter (inter-arrival gap minus inter-write gap per seq-adjacent pair; skew-free; the row is each run's MAX positive value, so one stall moves it)}

_{Scenarios — step: one trivial no-op step, no stream; no hooks, so the run stays in turbo mode (in-process fast path) · stream: one streaming step; no hooks, so the run stays in turbo mode (in-process fast path) · hook + stream: registers a hook before one step, which exits turbo mode (dispatch path) · 1020 steps: 1020 trivial sequential steps; STSO is measured between consecutive steps in the given step ranges, and WO is the whole-run overhead outside step bodies · Promise.all(100 steps): 100 trivial no-op steps started together in a single Promise.all; Fan-out TTFS is the first of them to complete and Fan-out TTLS the last, both from the in-deployment clientStart, so their gap is the spread the runtime adds across the fan-out · paced control (100/s, 60B): the control: 300 tiny (~60B) deltas metronome-paced at 100/s — zero workload structure, so it reads the transport floor and flush cadence, and disambiguates transport-wide vs workload-specific when a replay row moves · size sweep (100/s, 160B-12KB): same pacing as the control with deltas padded in rotation across seven log-spaced sizes (~160B–12KB) — rotation decouples size from stream position, so it isolates whether chunk size causes latency · replay gateway-gpt-5.4-nano-2000t (1x): raw provider SSE cadence captured at the AI gateway boundary (gpt-5.4-nano, the most popular gateway model; per-token deltas p50 208B = the modal production chunk size), replayed exactly as measured — the typical customer's workload; its CDV is the typical customer's real delivery jitter · replay eve-gpt-5.6-sol-2000t (1x): a captured eve turn (gpt-5.6-sol, the most-used demanding eve model; ~2000 output tokens = production p50 turn length) replayed exactly as measured — eve's envelope protocol re-ships the cumulative message so sizes ramp 142B→13KB; the demanding outlier tenant's reality · replay eve-gpt-5.6-sol-2000t (2x): the same eve capture at 2x — the headroom/stress row; real fast-tier models emit the same chunk sizes at proportionally higher rate, so time compression is a faithful speed model · first chunk (pooled): every run's seq-0 RTT pooled across all stream scenarios — the first chunk precedes any workload differentiation, so pooling samples one shared stream-open path with exact percentiles}

_{Replay cadences (semantic sha256) — eve-gpt-5.6-sol-2000t eaf22f5946e7c61f3c65c7006d550df180cfabd4e706254a09f22aec0cfb420d · gateway-gpt-5.4-nano-2000t 6f24ac518b6b83ff1d0e85a5fe78230db192716d66a7fc6b2fe022752001d041}

_{🔴 marks a percentile over its target (within target is left unmarked). Targets (p75/p90/p99, ms) — TTFS 200/300/600}

_{All timestamps are deployment-side; runs are triggered in-deployment, so the CI runner and api.vercel.com sit outside every measured window. TTFS = start() → first step body (includes dispatch + any cold start); Fan-out TTFS/TTLS = first/last step completion of one Promise.all from the same anchor (the gap is the runtime’s fan-out spread); STSO/WO between step bodies; CRTT inside the workflow (excludes the api.vercel.com read path).}

_{Cold starts stay in the numbers (real bursty-workload latency, inflates P75+); Best is the warm floor.}